-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start to untangle CoreServices/MixxxMainWindow initialization #4110
Start to untangle CoreServices/MixxxMainWindow initialization #4110
Conversation
780df49
to
1470d14
Compare
CoreServicesTest.TestInitialization failed. |
I guess the CI doesn't have everything available for such a test. Does it work locally? |
Ping. This decides whether I'll remove the test or remove it entirely. |
b1c6215
to
26f2bf1
Compare
26f2bf1
to
9eba44f
Compare
Pull Request Test Coverage Report for Build 1081813635
💛 - Coveralls |
I'm not sure about the first commit. VisualsManager and GuiTick are only for rendering the legacy skins, so I think it is appropriate to leave them in MixxxMainWindow. |
This seems to be hinting at a larger architectural issue that should probably be solved first... |
Would it be feasible to rebase to remove the first commit and continue working on decoupling the indicator ControlObjects from the QWidget GUI rendering? |
Or move them and leave a TODO about the required architectural refactoring and their removal. Just to be able to move forward. |
Tbh I'm not really sure what the scope of these classes actually is. From the source code: // This class updates the controls used for widgets and
// controller indicator, in a CPU saving way and outside the engine thread
class DeckVisuals { // A helper class that manages the "guiTickTime" COs, that drive updates of the
// GUI from the VsyncThread at the user's configured FPS (possibly downsampled).
class GuiTick { So it sounds like both classes only manage COs anyway? @Be-ing Are you sure you're not confusing them with |
I'll have to look deeper into the code which I don't have time to do at the moment (hopefully I will next week). In the meantime the other commits look good to me. |
DeckVisuals and GuiTick are both coupled to the rendering of the legacy QGLWidget waveforms. I don't think it is a good idea to try to get them to work with QML somehow. I think the ControlObjects should be reimplemented some other way for QML. We don't need to know what that new implementation will be yet. I think we should remove the first commit from this branch, merge the others, and add a to-do card to the QML project board for reimplementing those COs. |
It already "works" with QML right now. These are initialized because we use MixxxMainWindow at the moment.
OK.
Right now CoreServices is basically completely broken, because it cannot be initialized without GuiTick/VisualsManager although it should be self-contained. I suggest to leave the commit in and just add a comment. Initializing something that may be not be needed later is IMHO the lesser evil compared to not being able to initialize coreservices at all because some dependencies are missing. If you insist, I can also remove the commit. But this will block me from any further decoupling of the MixxxMainWindow class and the core mixxx initialization. |
It works because MixxxMainWindow calls WaveformWidgetFactory::startVSync. CoreServices should not have anything to do with WaveformWidgetFactory. It shouldn't start VSyncThread either, but I would be willing to accept that as temporary technical debt with a FIXME comment to keep these ControlObjects working.
I don't understand what you mean. CoreServices has nothing to do with these classes now; they are not required to initialize CoreServices. And that is how it should be because those classes are coupled to the QWidgets GUI. |
This is wrong. CoreServices fails to initialize without them. If you look here, you can see that the mixxx/src/waveform/guitick.cpp Lines 7 to 8 in f4e4807
These controls are used by mixxx/src/control/controlindicator.cpp Lines 12 to 13 in f4e4807
ControlIndicator is used by mixxx/src/engine/controls/cuecontrol.cpp Lines 172 to 173 in f4e4807
If you try to initialize CoreServices without initializing |
This hyperbolic language does not help move forward a technical discussion.
That is far from "completely broken". It's just a warning. Pedantically silencing warnings without addressing their cause isn't really helpful. Creating these ControlObjects is pointless without VSyncThread running. So please either remove the first commit and leave these COs broken for now or move the initialization of VSyncThread to CoreServices with a FIXME comment explaining why it does not belong there because it exists for the legacy GUI but those COs do not function without it. |
3173457
to
30538a2
Compare
Rebased on #4157.
And neither does denying that CoreServices cannot be initialized when
A DEBUG_ASSERT is not just a warning. It's always a bug. Either it shouldn't be possible to trigger it, or the DEBUG_ASSERT itself is wrong. In this case it's the former. That assertion is triggered every time you try to start Mixxx without Anyway, I fixed this in #4157 so it should work now without pulling in |
e38b6a0
to
cdb40c1
Compare
The `MixxxMainWindow` class should not be responsible for initializing `CoreServices`. Mixxx should still be able to work when there is no `MixxxMainWindow` (e.g. when we switch to a `QQmlApplication` for QML).
Before, CoreServices would cause a debug assertion when initializing it without other stuff from `MixxxMainWindow`. This is just a smoke test to verify that it's possible to initialize the `CoreServices` class on its own, without `MixxxMainWindow.
cdb40c1
to
b1017e0
Compare
Rebased on latest main. |
Do you plan to decouple DeckVisuals from QWidgets before or after this PR? |
&mixxx::CoreServices::initializationProgressUpdate, | ||
&mainWindow, | ||
&MixxxMainWindow::initializationProgressUpdate); | ||
pCoreServices->initialize(app); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be moved to the CoreServices constructor by passing the QApplication* as another argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we need the main window for monitoring progress during the initialization?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we need the main window for monitoring progress during the initialization?
Indeed. CoreServices are MixxxMainWindow are classes that communicate with each other via signals, but neither does MixxxMainWindow own CoreServices (as it did before) nor vice versa.
Hence, we need to construct both first, then connect the signals, then initialize them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is ready IMHO. The other PR still has open review comments. I suggest to merge this first. |
The COs from DeckVisuals are not strictly necessary for CoreServices, just needed in case some controller mappings use them. So we can do it later, or deprecate them if we deem necessary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that will conflict with my branch. Hopefully no problem to solve the conflicts.
LGTM, Thank you.
I added a to-do card to the QML project for decoupling DeckVisuals from VSyncThread. |
Based on #4109. This moves some required stuff like
GuiTick
/VisualsManager
intoCoreServices
(without them, CoreServices initialization will fail with a debug assertion). It also moves the call toCoreServices::initialize
out ofMixxxMainWindow
, because even without aMixxxMainWindow
theCoreServices
should be initialized (this will be necessary when we to a pure QML interface instead of embedding the QML UI inside aQQuickWidget
.)This is not yet complete, for example the sound setup (
setupDevices()
) should also happen inmain
, but this requires moving the preferences out of MixxxMainWindow, too. Unfortunately, these depend onWaveformWidgetFactory
which is not needed for QML. Hence, this will need some more refacoring in later PRs.